INFO-ATARI16 Digest Wed, 6 Dec 89 Volume 89 : Issue 761 Today's Topics: 1040st sound problem Atracting new Club members C question Form Doc's LYNX Development System Shareware MAC (3 msgs) Sozobon C, PageStream, Magic, NRPS ---------------------------------------------------------------------- Date: 6 Dec 89 01:25:57 GMT From: usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632!rit!ultb!drp9 500@ucsd.edu (D.R. Paradis) Subject: 1040st sound problem Message-ID: <1698@ultb.isc.rit.edu> I forget the part number but it is the General Instruments sound chip from Radio Shack. how do I know this......I had to replace mine and used this chip and it's been working like a champ for over a year! The chip is about $10 (standard 40 pin size) but they do have it. ------------------------------ Date: 6 Dec 89 17:54:42 GMT From: texbell!wuarchive!kuhub.cc.ukans.edu!shawl@rutgers.edu Subject: Atracting new Club members Message-ID: <19367@kuhub.cc.ukans.edu> The Lawrence Atari Computer Club (Lawrence, Kansas) meets in the public library. I would recommend trying that since it is centrally located, and FREE!! Steve Shawl bitnet: Shawl@kuhub.cc.ukans.edu ------------------------------ Date: 6 Dec 89 17:45:24 GMT From: galaxy.rutgers.edu!argus!ron@rutgers.edu (Ron DeBlock) Subject: C question Message-ID: <1381@argus.UUCP> Someone asked why main() ? char fred[] = "hello"; .... won't work, and a bunch of answers followed. Some made no sense, others were close, but I haven't seen the complete answere yet. So here it is: The error from the compiler on this line is probably something like: "No initialization of automatic agragate." This means that an aggragate structure (an arry, struct or union) that is automatically allocat cannot be pre-initialized. Automatics are any variables declared INSIDE of a function (this excludes the functions arguments). For non-aggragate variables, (int, *, cha the compiler will generate storage and code to initialize. It does not do so for aggragates. The solution is to make the variable non-automatic. Someone mentioned declaring the array as static char fred[] which will work just fine. Global variables are also not automatic, so moving the declaration outside of main() will also work. C provides the keyword "auto" to make variables automatic. I've never seen it used, since it is only valid within functi (or block) scope and it is the default. The "static" keyword has an interesting side effect: a global symbol declared as static only has file scope. This allows you to create global vaiables and functions which are visible only within a file: static int foo; int bar; static int bas() ? ... ? int baf() ? ... ? baf() and bar may be declareas extern in other files and used normally. However, foo and bas() CANNOT be referenced outside of the file! This is sometimes useful if you want to be sure that certain variables or functions cannot be accessed from other code. -- Ron DeBlock N2JSO Net: ...!rutgers!galaxy!argus US Mail: 42 Davis Street, Phillibsburg, NJ 08865 USA ------------------------------ Date: 6 Dec 89 05:11:21 GMT From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs) Subject: Form Doc's Message-ID: <1989Dec6.051121.21994@chinet.chi.il.us> I can whine with the best of them (and do, often enough). The point that .dvi isn't the most accessible form seems made. For those who can do nothing else, i suggest using either a strings program or a dump utility on the dvi: enough of the text is recoverable to let you know what the program is about. Steve J. ------------------------------ Date: 5 Dec 89 13:10:41 GMT From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU (Michael Portuesi) Subject: LYNX Development System Message-ID: >>>>> On 5 Dec 89 17:44:45 GMT, 2FHDBEAK@kuhub.cc.ukans.edu said: j> Here's an interesting tidbit for you LYNX fans: j> The development system for the Atari LYNX is an AMIGA computer! j> I wonder what it must be like to go into Atari's offices and see j> all sorts of Amigas lying about. That's not surprising, given that the Lynx was developed at Epyx, not Atari, and all the Lynx designers also designed the Amiga. --M -- __ \/ Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM Entry Systems Division -- Engineering He says, "Take me to your leader" -- and I say, "Do you mean....George?" ------------------------------ Date: 5 Dec 89 16:15:15 GMT From: att!drutx!druwy!dlm@ucbvax.Berkeley.EDU (Dan Moore) Subject: Shareware MAC Message-ID: <4476@druwy.ATT.COM> in article <3395@brazos.Rice.edu>, bro@titan.rice.edu (Douglas Monk) says: > The suggestion was made that instead of using a cartridge, code that works > like the MAC ROMs but doesn't violate Apple's copyright could be used. This > is a great idea. No one has done it yet, which is one of the reasons why no > Apple clones (other than STs :-) exist yet. ~~~~~~~~~~~~~~ not true, there is an Amiga Mac emulator. > It is a technical difficulty, or a legal one? How does Phoenix et al. get > away with IBM clone ROMs? Licensing? Work-alike? The problem is partly technical and partly legal (or at least lots of money for lawyers). To "legally clone" a BIOS (or ToolBox in Mac'ese) you need to teams of programmers and some lawyers. The first team studies the code to be duplicated and generates a highly detailed description of the code. The description would include statements about register contents, data structures passed, etc. for the various routines in the BIOS. It then states what the routine does including any side effects (eg. global variables that are changed). It should also document any bugs in the code (ie. deviations from the published specifications for the BIOS). This description is then sent to the lawyers who save copies of everything (documentation for any suits that come up) and then send a copy to the second programmer team. The second progammer team has to be made up of people who have NEVER looked at the actual code to be duplicated (ie. they never used a debugger to look at the Mac ROMs or the IBM PC BIOS or whatever). They also can NOT talk to the first programmer team except by having the lawyers forward messages (which are filed just like everything else.) They then use the descriptions to write routines that do the exact same thing as the original. They may even clone the bugs, some of the 3rd party EGA cards for PC's have the same bugs as IBM's EGA card. When you get done you have what should be a legal duplicate of the first program's functionality. There may be problems due to copyrights on the visual appearance (look & feel) or patents on algorithims, etc. Hopefully the documentation the lawyers have will be enough to prove that you did things legally (Phoenix pulled it off with BIOS ROMs for PC's). The technical problems are really just time problems. The Mac ROMs are very complex (much more complicated than the TOS ROMs for instance). Given the large number of functions contained in the ROMs it will take quite a while to duplicate them. And while they are working to duplicate a given release of ROMs (eg. the 256K ROMs in the Mac II) Apple will be working on new, improved ROMs with new features. So when you get done you may have something that is already obsolete. This isn't a problem with cloning the BIOS ROMs in a PC, the functions of those ROMs is pretty stable with very few changes over time. No company has decided that the time and expense (at least one year, at least 10 or 20 programmers, plus lawyers, and Apple will sue when you get done) is worth the expected return. Dan Moore AT&T Bell Labs Denver dlm@druwy.ATT.COM ------------------------------ Date: 4 Dec 89 15:34:59 GMT From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU (Michael Portuesi) Subject: Shareware MAC Message-ID: >>>>> On 29 Nov 89 14:30:00 GMT, greg.trice@canremote.uucp (GREG TRICE) said: greg> Why does everybody assume that a Mac emulator has to use Mac ROMs or any greg> Mac code at all? There are an infinite number of ways to do a given job greg> and it is perfectly possible for somebody to carefully read all the Mac greg> documentation and then sit down and write code that will do exactly the greg> same job as the Mac roms, but have not a byte in common with them in greg> code. This is the situation with most IBM compatible systems. Though greg> they are functionally identical to the IBM product, their ROMs contain greg> different, but functionally identical code. greg> It should be perfectly possible to produce a Mac emulator that used no greg> ROMs at all, but was wholly disk based (given sufficient memory to hold greg> the quondam ROM code in RAM). Go ahead and try...I'll see you in a few years. The Apple ROMS are the result of several hundred person-years of work, and you expect one enterprising hacker to recode them, and do all of the testing and revising to ensure even a reasonable amount of compatibilty? Obviously you've never developed software for a living. --M -- __ \/ Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM Entry Systems Division -- Engineering He says, "Take me to your leader" -- and I say, "Do you mean....George?" ------------------------------ Date: 6 Dec 89 17:35:00 GMT From: apollo!rehrauer@eddie.mit.edu (Steve Rehrauer) Subject: Shareware MAC Message-ID: <474461c0.20b6d@apollo.HP.COM> In article <3395@brazos.Rice.edu> bro@titan.rice.edu (Douglas Monk) writes: >The suggestion was made that instead of using a cartridge, code that works >like the MAC ROMs but doesn't violate Apple's copyright could be used. This >is a great idea. No one has done it yet, which is one of the reasons why no >Apple clones (other than STs :-) exist yet. > >It is a technical difficulty, or a legal one? Primarily the former, secondarily the latter. To "do it right"; i.e.: to avoid committing legal hari-kari, companies use what I've heard called a "clean room" approach. Two design teams work on the problem. Team #1 looks at the *specifications* for what they're trying to clone. It's probably fair for this team to look at ROM images, but I'm sure it'd be better if they didn't. Team #1 generates their own specs for how to functionally reproduce what is to be cloned. Team #2 only sees this spec, and can never look at the original materials team #1 used. No fair going to team #1 and saying, "Hey, we're having a hard time seeing how to do 'bletch'; how did They do it?" If the original specs were accurate, and team #1 did a good job, and team #2 did a good job, the clone works well. And even after all that, if the opposition is sufficiently larger than yourself, they may be able bleed you dry in court. You may be perfectly legal in what you've done, but proving it takes time and $$$. > How does Phoenix et al. get >away with IBM clone ROMs? Licensing? Work-alike? What's in IBM ROM BIOS is surely an order of magnitude (or more) easier to reverse-engineer than what's in Mac ROMs. Not to mention that it's (at least originally, and perhaps still) far more lucrative if you succeed with IBM BIOS. Don't hold your breath for Mac OS clones. Apple has shown itself to be quite willing to vigorously defend what it considers its turf, whether "common sense" says they have a case or not. The cost of developing a Mac clone "done right", plus the possibility of locking horns with Apple in court afterwards, is enough to scare away most of the cloners. I'd expect to see Apple license their ROMs before we see clones, and they haven't been too receptive to that idea either. -- >>"Aaiiyeeee! Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com "Flee, lest we be trod upon!" | The Apollo System Division of H.P. ------------------------------ Date: 5 Dec 89 11:00:00 GMT From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!glk01126@iuvax.cs.indiana.ed u Subject: Sozobon C, PageStream, Magic, NRPS Message-ID: <111500076@uxa.cso.uiuc.edu> To the authors of Sozobon: great job on version 1.2, when is the final release coming? I have finally deceiphered the format of PageStream files and wrote (for a class) a magic (VLSI CAD SYSTEM) to PageStream file converter if anyone is interested. This will allow you to work on VLSI in a PageStream Document and port it... (with limited error checking) or to include your VLSI documents in PageStream documents. I am going to start a graphing program that will output to PageStream format files. I have not decided yet if I should try to contact SoftLogic for possible marketing (GraphStream) or release it as shareware... Anyone have any advice? Has anyone done any reviews on products and sent them in to a magazine? I would like to review Sozobon C and get the message out that an excellent PD C is available. To the requesters of Neodesk Random Picture Selector... It is available at terminator (35.1.33.8) in atari/new/nrps.arc. Version 2.0 is coming soon that will extract a random picture from .zoo,.lzh or .arc files and use that. (getting sick of all the space required for the pictures) If you can't access terminator, get your request to me or let me know how to post it to comp.binaries.atari.st. -Gregory Mathias Lemperle-Kerr "Ahhh the University of Illinois, what a joy..." ------------------------------ End of INFO-ATARI16 Digest V89 Issue #761 *****************************************